fuzz: Skip wasm-split tests on modules with __indirect_function_table - #9092

Path B Proposal (RFC)

Summary
Path A (fuzzer skip) unblocks fuzzing but does not fix the root cause: wasm-split still reuses an Emscripten‑style __indirect_function_table instead of creating a fresh one, which corrupts the table when the primary module contains call_indirect instructions.

This comment proposes Path B: remove the Emscripten special‑case logic and always create a fresh table for split‑module indirect calls. Before writing any code, I'd like feedback on the design and on the Emscripten coordination aspect.

Reproducer

The following minimal module reproduces the problem when wasm-split is run on it with at least one function kept in the primary module:

(module
  (table $__indirect_function_table 2 funcref)
  (export "__indirect_function_table" (table $__indirect_function_table))
  (elem (i32.const 0) $0)
  (func $0 (call_indirect (i32.const 0)))
  (func $1)
)

Before the fix, wasm-split reuses __indirect_function_table, and the primary module's call_indirect collides with the secondary module's element segment writes.

Root cause

src/ir/module-splitting.cpp, TableSlotManager constructor (around lines 165–177):

  Export* emscriptenTableExport =
    module.getExportOrNull("__indirect_function_table");
  Table* singletonTable =
    module.tables.size() == 1 ? module.tables[0].get() : nullptr;
  bool emscriptenTableImport =
    singletonTable && singletonTable->imported() &&
    singletonTable->module == "env" &&
    singletonTable->base == "__indirect_function_table";

  if (module.features.hasReferenceTypes() && !emscriptenTableExport &&
      !emscriptenTableImport) {
    return;
  }
// otherwise reuse the existing table

This special case was added in #7050 because the Emscripten loader could not handle more than one table.

Proposed change (Path B)

Remove the emscriptenTableExport / emscriptenTableImport checks and always enter the "create fresh table" branch when reference types are enabled. The primary and secondary modules then use a dedicated table for split-function indirect calls, leaving __indirect_function_table untouched.

Open questions

Emscripten coordination. @dschuff noted earlier that the loader "just needs to figure out which table to patch." Is the Emscripten side ready, or does this PR need to be gated on a loader update? If the loader still cannot handle multiple tables, Path B would regress Emscripten builds.

Alternative: Keep the reuse behavior but make wasm-split refuse to split when the module has __indirect_function_table and a non-trivial primary (i.e., fail loudly instead of silently corrupting). This is less invasive but less useful.

Test coverage. What lit tests and Emscripten integration tests should be added before this lands?

Plan

Path A (fuzzer skip) lands first to stop the fuzzer crashes.
This comment gathers feedback on Path B.
Once the design is agreed, Path B will be implemented in a separate PR.

Looking back at #8106, it looks like the best fix would be to have Emscripten correctly handle the presence of a second table and then remove the table reuse logic in wasm-split. Is that what you mean by this in the PR description?

Follow-up: A separate PR will address the root cause in src/ir/module-splitting.cpp by no longer reusing Emscripten tables (Path B).

If so, do we even need this intermediate fix?

If there are no plans to update Emscripten in the near term, though, then this fix looks good to me.